W05 Bewertung

Versionsverlauf:

Änderungen und Klarstellungen sind weiterhin möglich.

Punkteverteilung

In Ausnahmefällen (Streit im Team oder mit AGs, Betrugsversuche, langanhaltende Krankheitsfälle, ...) behält sich die Projektorganisation das Recht vor von der Punkteverteilung abzuweichen.

Abgabeformate

Abgaben erfolgen als PDF. Es ist kein Format vorgegeben, wählt etwas das für euer Team einfach zu erstellen ist. Achtet auf allgemeine Leserlichkeit. Seitenangaben rechnen sich um als 1 Seite entspricht 400-500 Worten (dies entspricht typischen Templates, weicht euer Template davon ab Zählt bitte die Wörter damit eure Abgabe nicht zu lang wird). Graphiken sind explizit erwünscht und zählen nicht zum Seitenlimit. Seitenlimits sind ein hartes Maximum. Kürzere Texte, die alles Wichtige enthalten, sind oft besser als das Maximum voll auszunutzen.

Benotung durch AGs

Die Benotung im Teamprojekt Softwareentwicklung ist schwierig in ein exaktes Schema zu fassen, da jedes Projekt und jedes Team unterschiedlich ist. Wichtig ist, dass der gesamte Prozess und nicht das Endergebnis bewertet wird. Auch wichtig ist, dass die Bewertung für das Team nicht überraschend ist, Probleme sollten vorher kommuniziert werden.

Wir bitten sie das Team auf einer Skala von 0 bis 100 zu bewerten. Dabei entspricht 49 Punkte oder weniger einem „5.0 nicht bestanden“.

Berücksichtigen Sie bei der Bewertung bitte folgende Punkte.

Wenn sie bei den meisten (sagen wir 9 von 11, etwa 80%) der obigen Punkte mit „Ja/Gut“ Antworten würden sind 100 Punkte als Bewertung angemessen.

Falls das Team regelmäßig an den Meetings teilgenommen hat, auch wenn nicht immer gut vorbereitet, und Anforderungen bearbeitet hat, sodass am Ende zumindest minimale nutzbare Software entstanden ist, sollte das Team nicht durchfallen (50+ Punkte).

Für Ergebnisse dazwischen überlassen wir die genaue Gewichtung der obigen Punkte ihnen. Gewichten sie ihre Bewertung danach, was sie dem Team als besonders wichtig kommuniziert haben. Ganz grob könnte jeder der 11 obigen Kriterien etwa 5 Punkte mehr in der Bewertung sein, ausgehend von 55 Punkten für die ausreichende Teilnahme am Projekt.

Typisches Beispiel für 100 Punkte wäre: Das Team hat bei jedem Treffen Fortschritt gezeigt. Anforderungen mit Akzeptanzkriterien entsprechen ihren wünschen. Es gibt zwar nicht erfüllte Anforderungen, aber die Grundfunktionalität der Software ist vorhanden, und das Team hat einen klaren Plan gehabt wie man den ursprünglichen Plan was umgesetzt wird an die Realität anpassen kann.

Typische Beispiele für Teams die durchfallen (weniger als 50 Punkte):

Berücksichtigen Sie bei der Bewertung auch gerne, wenn das Projekt besonders schwer oder einfach war, falls sie dies Beurteilen können (z.B. durch vorherige Erfahrungen mit ähnlichen Studierendenprojekten). Berücksichtigen Sie dabei aber bitte auch, dass es für die Studierenden oft viel schwieriger ist sich in unbekannte Projekte einzuarbeiten als Sie das erwarten würden. Wenn sie sich eine „Standard Webanwendung“ gewünscht haben, aber das Team keine Vorerfahrung mit Webanwendung hat, soll dies nicht übermäßig als Nachteil ausgelegt werden. Wohingegen natürlich schon erwartet werden kann, dass das Team die reichlich vorhandene Dokumentation zu solchen Anwendungen im Internet nutzt, und sich in das Thema einarbeitet.

Projektdokumentation

Siehe Moodle für Abgabedatum.

Die Projektdokumentation ist ein schriftlicher Beleg, dass der Softwareentwicklungsprozess ordentlich durchgeführt wurde. Behauptungen in diesem Dokument werden durch die Teambegleitungen geprüft.

Das Dokument sollte sich in drei Kapitel unterteilen: Projektbeschreibung, Entwicklungsprozess, Fazit. Abweichungen sind möglich aber unüblich.

Den Hauptteil der Bewertung macht die Beschreibung des Entwicklungsprozesses. Die Projektbeschreibung und das Fazit gehen in den „Gesamteindruck“ des Dokuments ein. Gute Reflexion über das Projekt im Fazit kann andere schwächen in der Gesamtbewertung ausgleichen.

Projektbeschreibung (maximal 2 Seiten)

Dient dazu, um einen Überblick über das Projekt zu gewinnen, sodass die Projektdokumentation für die Projektorga verständlich ist ohne das Projekt zu kennen.

Entwicklungsprozess (maximal 4 Seiten)

Der Entwicklungsprozess ist der Hauptteil eurer Note. Nennt in der Bewertungsliste was ihr geleistet habt. Beschreibt im Fließtext interessante Details, und worauf ihr Stolz seid. Gebt Beispiele, fügt Screenshots ein, helft der Projektorga einen schnellen Überblick über das zu bekommen, was ihr in dem Semester getan habt.

Denkt auch daran einen überblick über euren Prozess zu geben:

Bewertungsliste

Erstellt eine Liste/Tabelle an von euch geleisteter Arbeit im Entwicklungsprozess. Diese Punkte stellt die Grundlage eurer Bewertung dar. Achtet insbesondere darauf, dass ihr alles was ihr zu den Punkten Anforderungen? und Qualitätssicherungsmaßnahmen? erledigt habt auch in der Liste erwähnt. Eure Teambegleitungen Prüfen, dass ihr alle genannten Punkte durchgeführt habt.

Der Fließtext sollte die Punkte aus der Bewertungsliste aufgreifen, und gegebenenfalls erläutern.

Beispiel für einen Teil einer mögliche Bewertungsliste

Arbeitszeit und Planung

Wir erwarten von euch einen Burn-Down-Chart der eure Planung und Schätzungen visualisiert. Beispiele:

In eurem Burndown-Chart sind von links nach rechts (x-Achse) die Iterationen und von oben nach unten (y-Achse) die verbleibenden Story Points (oder Stunden, falls ihr in konkreter Zeit geschätzt habt). Der Punkt ganz links oben zeigt die Gesamtsumme der Story Points aller eurer Anforderungen. Die Optimallinie verläuft dann linear nach rechts unten, bis in der letzten Iteration keine offenen Story Points mehr übrig sein sollten. In der Linie für die tatsächliche Bearbeitung tragt ihr immer ein, wie viele Story Points am Ende der jeweiligen Iteration noch übrig sind. Bei jedem Schritt nach rechts verringert sich die Höhe also um die Story Points, die in dieser Iteration abgeschlossen wurden.

Falls ihr nicht alle Anforderungen abgearbeitet habt, erreicht die Linie nie die 0. Dies kann durchaus normal sein, wenn ihr mehr Anforderungen aufgenommen habt, als ihr im Zeitrahmen bearbeiten konntet.

Desweiteren erwarten wir von euch einen Pie-Chart in dem ihr die Verteilung eurer Arbeitszeit in die verschiedenen Kategorien auflistet. Die Kategorien sind nicht fest vorgegeben. Sinnvolle Kategorien beinhalten: Entwicklung, Dokumentation, Testen, Code Reviews, Pair Programming.

Anforderungen?

Qualitätssicherungsmaßnahmen?

Fazit (maximal 1 Seite)

Abschlussvortrag

Vortragsszenario: Euer Team wird im Rahmen einer Budgetneuverteilung evaluiert. Es ist eure Aufgabe mich zu überzeugen:

Fragen werden sich auf euren Prozess und insbesondere die Qualitätssicherungsmaßnahmen fokussieren. Ziel ist es, dass wir einen Überblick bekommen wollen, ob ihr euer Projekt repräsentieren könnt, und ob alle Teammitglieder beteiligt waren.

Beispiele

Wie fällt man durch?

Wie bekommt man eine sehr gute Note?

FAQ

Wie verhält es sich mit Verwendung von Graphiken innerhalb von Präsentationen bzw. der Projektdokumentation?

Generell gelten im TPSE (wie auch in allen anderen Lehrveranstaltungen dieses Fachbereichs) die Grundregeln der Wissenschaftsethik -- auf der Infoseite des Fachbereichs zu diesem Thema finden sich auch Hinweise und weiterführende Links zum korrekten Zitieren, die bei allen Abgaben einzuhalten sind hier.

Für nur im Rahmen von internen Präsentationen verwendeten Bildern reichen dabei Links, welche die Bildquelle angeben. Bedenkt aber das ganze Folien, Beispiele, oder ähnliches übernehmen nur in bestimmten Ausnahmefällen akzeptabel ist. Insbesondere dürfen Architekturdiagramme oder ähnliches nicht einfach übernommen werden. Im Zweifelsfall erstellt an eure eigenen Graphiken.

Ist die Größe der Abgabe der Projektdokumentation als Datei festgelegt?

Moodle erlaubt keine Dateien >20MB. Solltet ihr diese Größe überschreiten müsst ihr die zu großen Inhalte extrahieren und anderweitig verfügbar machen. Kontaktiert hierzu bitte eure TBs.

Wie sollen wir die Nachweise über die durchgeführten QS-Maßnahmen dokumentieren, wenn wir diese beispielsweise in GitHub gepflegt haben?

Stellt bitte sicher das eure TB Einsicht in eure Prozesse hat, und dokumentiert den Prozess in der Projektdokumentation.

Müssen die Dokumente neben der Projektdokumentation ein bestimmtes Dateiformat einhalten?

Bitte nur Standardformate abgeben. Das bedeutet hauptsächlich: .pdf .txt .jpg .png und .html ohne externe Inhalte.

Referenzen

Rundung von Noten aus den APB

Allgemeine Prüfungsbestimmungen der (7. Novelle)

§ 25 Bildung und Gewichtung der Noten

4) Zur Berechnung der Modulnote mit dem BWS „Standard“ werden die ersten drei Dezimalstellen hinter dem Komma berücksichtigt; alle weiteren Stellen werden ohne Rundung gestrichen. Daraus ergeben sich folgende Notenstufen:

1,0 bis 1,199 = 1,0 (sehr gut) 1,2 bis 1,599 = 1,3 (sehr gut) 1,6 bis 1,899 = 1,7 (gut) 1,9 bis 2,199 = 2,0 (gut) 2,2 bis 2,599 = 2,3 (gut) 2,6 bis 2,899 = 2,7 (befriedigend) 2,9 bis 3,199 = 3,0 (befriedigend) 3,2 bis 3,599 = 3,3 (befriedigend) 3,6 bis 3,899 = 3,7 (ausreichend) 3,9 bis 4,099 = 4,0 (ausreichend) ab 4,1 = 5,0 (nicht bestanden)

Punktetabelle

Die verwendete Punktetabelle ist:

Note	Punkte
-----------------------
1.0  	95 – 100
1.3  	90 – 94
1.7  	85 – 89
2.0  	80 – 84
2.3  	75 – 79
2.7  	70 – 74
3.0  	65 – 69
3.3  	60 – 64
3.7  	55 – 59
4.0  	50 – 54
5.0  	0  – 49